The so-called Machine-To-Machine (hereinafter M2M) is a further development of telecommunication networks whereby devices connected thereto, namely M2M Devices, are managed and instructed from dedicated servers, namely M2M Servers, through different routers and gateways, which are nowadays specialized entities in the M2M market.
An exemplary M2M system may be one comprising a so-called capillary network with a plurality of temperature sensors distributed amongst trees of a forest, a server connected to the capillarity network likely through a public telecommunication network, this server receiving temperature data from the sensors and processing them to determine whether any anomalous condition may be established, such as a fire, and likely connected with emergency systems.
Another exemplary M2M system may be one comprising a number ‘n’ of containers distributed in a number ‘m’ of trucks, where n>m and wherein each truck thus transports one or more containers, a server for tracking the current geo-position of each truck and, as assuming the server knows which container is in which truck, thus tracking the current geo-position of each container. Moreover, also in this exemplary M2M system, each container may be equipped with temperature sensors and controllers so that the server might influence the temperature of each container.
Many M2M systems already exist nowadays, likely including M2M Devices of very different nature and controlling functions of different types in each M2M Server.
The exponential grow of the M2M market, as quite a few analysts expect, implies for telecommunication network operators the expansion from millions of users to billions of M2M Devices. It is reasonably expected that the M2M market will cover a much wider spectrum beyond capillary networks of different type of sensors and the potential market derived thereof will increase even more.
At present, the M2M service providers and some telecommunication operators are currently developing value-added and end-to-end solutions for the M2M industry. Moreover, the current approaches consist of ad-hoc end-to-end solutions for specific vertical applications.
As already commented above, a basic M2M architecture includes a plurality of M2M Devices, in particular ‘sensors’, connected to each other following different patterns such as, for example, a ring-connection or a star-connection, and they all connected with a so-called M2M Gateway responsible for establishing a communication with a remote controller, namely an M2M Server, through a public network. In this situation, especially where referring to sensor networks, some of the communication patterns of M2M Devices make the direct connection towards public networks inefficient and costly.
In some cases, the number of M2M Devices required to provide an M2M service is very high and the information transmitted from and to each M2M Device is quite poor in volume and frequency. In other cases, the information is only relevant in relation with the information provided by other M2M Devices, so that the establishment of a specific communication channel towards public network cannot be efficient or justifiable from a cost perspective. The M2M service providers and operators developing end-to-end M2M solutions are thus facing some difficulties that preclude an easy and flexible deployment of M2M Devices. Currently, the M2M Device is tied to a specific capillarity network and to a specific M2M Gateway due to the configuration needed for correct inter-working.
The integration of M2M communications over public networks currently presents some limitations such as those exemplary disclosed in the following.
A first exemplary scenario illustrating the current limitations may be a fire-detection system in a forest, wherein one may assume that thousands of cheap temperature sensors, namely M2M Devices, are deployed on the forest and communicate with a supervision centre, namely an M2M Server, via one or more M2M Gateways. This deployment presents some drawbacks: first, the M2M Gateways and the M2M Server have to know each sensor before deployment; second, the communication between the M2M Devices and the M2M Server requires specific media streams; and third, most of the information flows used to provide the measured temperatures is not relevant for the fire-detection system.
A second exemplary scenario illustrating the current limitations may be a Logistic management with flexible trunks and containers. This deployment also presents some drawbacks: first, if the containers, namely M2M Devices, are wanted to establish an independent communication with a logistic control, namely M2M Server, the truck where each container is located may have an influence; second, the communication between the truck, the multiple containers transported therein, namely M2M Devices, and the M2M Server requires specific media streams; and third, some information such as the location, common for all the containers in the same truck is required to be handled independently per container basis.
Currently no specific support exists in public networks to optimize these scenarios. Particularly in some cases, the number of M2M Devices required to provide any M2M service is very high and the information transmitted for each M2M Device is very low in terms of volume and frequency. Also particularly in other cases, the information is only relevant in relation with information provided by other M2M Devices. In most of these cases, establishing a specific communication channel towards a public network cannot be efficient or justifiable from cost perspective. In summary, current public networks do not have mechanisms to optimize the transmission supported by M2M Devices connected thereto based on semantic information.